Method and system for monitoring a supply-chain

ABSTRACT

A method of monitoring supply chain activity throughout a plurality of supply chain sites includes extracting, at each supply chain site, supply-related data to be monitored. The data is maintained in plural formats at the supply chain sites, and translated the data to a common format. The extracted data is then uploaded to and collected, from each supply chain site, to a data collection center or site. Upon a user request, a portion of the collected data is formatted, at the data collection site, into one of a plurality of views, responsive to criteria selected by the user, for presentation to the user, the portion of formatted data being dependent on access rights granted to the user&#39;s supply chain site. Finally, the formatted data view is published to the user&#39;s supply chain site. The data collection center comprises a data collector in which the uploaded data is stored, and a publisher for publishing data from the data collector upon request. Each supply chain site has a data storage device for maintaining its own supply-chain data, a data transfer engine (DTE), for transferring the supply-chain data to the data collection center, input means for allowing a user to query the data collector, and a display for displaying data published by the publisher in response to a query. The inbound data received from the multiple supply chain sites is monitored at the data collection site. If a problem condition is detected, such as a forecasted or present shortage or surplus, an alert is asserted, for example, by highlighting an Alert indicator, such as an Alert tab, on a user screen. Upon selection of the highlighted Alert indicator by a user, details of the detected problem condition are displayed.

RELATED APPLICATION

This Application is a continuation of U.S. application Ser. No.09/546,347, filed Apr. 7, 2000, which claims the benefit of U.S.Provisional Application No. 60/147,670 filed on Aug. 6, 1999, and isrelated to application Ser. No. 09/544,916, filed Apr. 7, 2000; theentire teachings of which are incorporated herein by reference in theirentirety.

BACKGROUND OF THE INVENTION

A typical manufacturing supply chain includes an original equipmentmanufacturer (“OEM”), which designs and sells equipment such ascomputers or other electronic equipment. To keep costs down, OEMs oftencontract out the manufacture of at least some of the individualcomponents of the product, such as electronic boards, to contractmanufacturers (“CMs”). The CMs must obtain the parts with which to buildthe boards, such as resistors and integrated circuits, which aremanufactured by component manufacturers or vendors. The components aretypically not sold directly to the CMs but rather are sold throughdistributors.

For example, FIG. 1A illustrates a supply chain 2 as is well known inthe art. Included in the supply chain 2 are a distributer 16, anoriginal equipment manufacturer (OEM) 12, one or more contractmanufactures 14, and one or more vendors 18. As indicated in the figure,each of these sites must communicate with one or more of the other sitesas indicated by the arrows.

Each node or link in the supply chain, i.e., each OEMs, distributor, CMand vendor, typically maintains its own private database to track andcontrol inventory, place orders, receive orders, enterprise resourceplanning (ERP), material requirements planning (MRP), etc. While thesesupply chain sites share some data, the data is typically maintained inincompatible formats in legacy databases.

The Electronic Data Interchange (“EDI”) standards have been developed toaid in the interchange of information to expedite business transactionsby specifying a consistent data interchange format. Yet, in practice,how each supply chain site deals with its external environment, i.e.,vendors, CMs, customers, has often been archaic and inconsistent.

Supply chain management is difficult because it depends on the axiomthat a business has fundamentally correct processes. Unless thefoundation for activity is well thought out, managing the chain furtheraggravates a company's environment. For example, not all of theinformation needed may be available on the legacy databases. Often,teams of programmers are utilized to implement custom design changes tothese legacy databases that become overwhelmingly complex. Whether thesechanges are implemented by outside consultants or by in-house staff,lack of clear project goals, effective monitoring and performance reviewconstantly plague the process.

SUMMARY OF THE INVENTION

The present invention eliminates much of the confusion which resultsfrom redesigning one or more complex legacy systems. Instead, legacysystems are left intact, and a data transfer engine (“DTE”) is installedat each site. The DTE monitors the local system continuously, and takeswhatever information is available. While a complete picture of thesupply chain may not be provided if not all information is available,for example, if a certain attribute is not tracked at a particular site,the DTE takes whatever data is available, cleans up the data, andformats the data into a common format acceptable to a data collectionsite. The DTE then transmits or uploads the data to the data collectionsite, which is preferably a distributor or an OEM.

While some custom programming is required to extract the properinformation and clean it up, no change to the existing business processis required. The programming that is required for extracting andcleaning the data is minimal compared to the major rewriting orrestructuring necessary for previous known methods.

The ability to collect data and lay it out before a user in logicallyconfigured views where sources and demands are made visible, and whereevery view is within two or three mouse clicks away, gives unprecedentedpower to OEMs and distributors to monitor, analyze and control thesupply chain. The present invention provides information management andanalysis capabilities at the component level for manufacturers, vendorsand distributors operating in partnership to manufacture subassembliesthat combine to produce a finished OEM product.

The present invention facilitates the relationships between the OEM,distributor, CMs and vendors (collectively, the “sites”) in the contextof raw materials flow through the supply chain. A great benefit of thepresent invention lies in its ability to aggregate or collect, analyze,and inform multiple parties about the status of materials that movethrough their shared supply chain, directly influencing the success ofeach.

Accordingly, a method of monitoring supply chain activity throughout aplurality of supply chain sites, includes extracting, at each supplychain site, supply-related data to be monitored. The data is maintainedin plural formats at the supply chain sites. The extracted data is thenuploaded to and collected, from each supply chain site, to a datacollection center or site, where it is stored in a common format. Upon auser request, a portion of the collected data is formatted, at the datacollection site, into one of a plurality of views, responsive tocriteria selected by the user, for presentation to the user, the portionof formatted data being dependent on access rights granted to the user'ssupply chain site. Finally, the formatted data view is published to theuser's supply chain site.

The data collection center comprises a data collector in which theuploaded data is stored, and a publisher for publishing data from thedata collector upon request. Each supply chain site has a data storagedevice for maintaining its own supply-chain data, a data transfer engine(DTE), for transferring the supply-chain data to the data collectioncenter, input means for allowing a user to query the data collector, anda display for displaying data published by the publisher in response toa query.

In one embodiment, the data is translated at each supply chain sitebefore uploading. Alternatively, the data is translated at the datacollection site after uploading.

In one embodiment, each supply chain site is scanned at regularintervals for new or changed data. Upon finding new or changed data, thenew or changed data are uploaded to the data collection site.

Plural formats can include, but are not limited to, spreadsheets,relational databases and text files. One skilled in the art wouldrecognize that spreadsheets and databases themselves vary from vendor tovendor, and even two implementations using the same vendor's spreadsheetor database or text file will have data configured and/or formatteddifferently.

Data can include, but is not limited to, inventory data, purchase ordersand lead time.

Data at the supply chain sites can be stored in legacy databases, thatis, databases, spreadsheets, text files, and the like, which existbefore implementation of the present invention.

In a further embodiment, the inbound data received from the multiplesupply chain sites is monitored at the data collection site. If aproblem condition is detected, such as a forecasted or present shortageor surplus, an alert is asserted, for example, by highlighting an alertindicator, such as an alert tab, on a user screen. Other possible alertcondition indicators are, for example, a highlighted box or button, or aline of data in one of the screens corresponding to, say, a part numberwhich is in an alert condition.

Upon selection of the highlighted alert indicator by a user, details ofthe detected problem condition are displayed. In one embodiment, thealert details are displayed in a bar graph. In another embodiment, alertdetails are displayed in a line graph.

In one aspect of the invention, animation is used to present data to auser. Specifically, data sets are shown within a historical basis andchanges are shown evolving in animated real time.

Supply chain sites can include any or all of contract managers (CMs),vendors, distributors and an original equipment manufacturer (OEM).

In one embodiment, the data is encrypted before uploading.

Preferably, uploading the data is performed over the Internet.

In a further embodiment, materials requirements information are providedfor a product at any or all stages in the product's lifecycle.

An analysis report is generated responsive to report selection by auser. The generated report is provided, responsive to user selection ofreport destinations, by emailing, printing, storing as a file ordisplaying on a monitor or a screen, the report.

Data is displayed in a window at a site's display according to acategory selected by a user at the site, in response to authorizationgranted, for example, to the site, or to the user.

For each category, at least one analysis filter is selectable by theuser for setting criteria to be used in filtering the data to bedisplayed. Filtering can include, for example, sorting and/or excludingcertain data. Filters are preferably organized hierarchically.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescription of preferred embodiments of the invention, as illustrated inthe accompanying drawings in which like reference characters refer tothe same parts throughout the different views. The drawings are notnecessarily to scale, emphasis instead being placed upon illustratingthe principles of the invention.

FIG. 1A is a block diagram illustrating a typical supply chain as knownin the prior art.

FIG. 1B is a block diagram illustrating a typical supply chain in whichthe present invention is employed.

FIG. 1C is a schematic diagram illustrating that part of the presentinvention to be employed at each participating supply chain site.

FIG. 1D is a schematic diagram illustrating that part of the presentinvention to be employed at the data collection site.

FIG. 1E is a flowchart of the process employed by an embodiment of thepresent invention.

FIG. 2 is a screen shot of a login window employed by the presentinvention.

FIG. 3A is a screen shot of board data for all active boards, sorted byboard number.

FIG. 3B is a screen shot similar to that shown in FIG. 3A, showing theassociated pull-down menu.

FIG. 3C is a screen shot of board data resulting from the selection madefrom the pull-down menu shown in FIG. 3B.

FIG. 4 is a screen shot of board data for boards using parts sold by aparticular distributor.

FIG. 5A is a screen shot of parts demand information for a particulardistributor.

FIG. 5B is a screen shot similar to that of FIG. 5A, showing theassociated pull-down menu.

FIG. 5C is a screen shot of parts information showing demand throughlead time for a particular part, resulting from the selection made fromthe pull-down menu shown in FIG. 5B.

FIG. 6 is a screen shot of MRP data by board.

FIG. 7A is a screen shot of vendor data.

FIG. 7B is a screen shot similar to that of FIG. 7A, showing theassociated pull-down menu.

FIG. 8 is a screen shot of sales data.

FIG. 9 is a screen shot of the reports ordering window.

FIG. 10 is a screen shot of a typical report sent to the screen.

FIGS. 11A-11C are screen shots of the alert window of the presentinvention.

FIG. 11D is a screen shot of an alternate alert window for use with thepresent invention.

FIG. 12 is a graph illustrating the use of animation by the presentinvention to present data.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1B illustrates a supply chain 10 environment in which the presentinvention is employed. An original equipment manufacturer (“OEM”) 12designs products, assembles the products or contracts assembly out,receives sales orders (“SOs”) from customers and generates purchaseorders (“POs”) to obtain the parts required to build the orderedequipment.

The POs may be sent to contract manufacturers (“CMs”) 14, who build, forexample, boards which typically have 50 to 200 or more parts. The OEM 12may contract with several CMs 14 to build the same board, and/or maycontract with different CMs for different boards. Here, for example,several contract manufacturers CM-A through CM-D are depicted.

The CMs 14 themselves must obtain the required parts or components, suchas resistors, capacitors, semi-conductors, knobs, indicators, hinges,switches, buttons, etc., either directly from the componentmanufacturers, or vendors 18, or more typically, from one or moredistributors 16, who generally keep inventories in stock which they (thedistributors) believe will satisfy foreseeable demand.

In addition, depending on how much of the manufacturing process the OEM12 retains for itself, the OEM may also obtain parts directly fromvendors 18 or through distributors 16.

Different components and boards have different lead times, which may bedependent on the availability or lead times of components, in the caseof boards, or other factors, such as a particular vendor's or CM's buildschedule. That is, different items take longer than others to order,design, produce, ship etc.

Each of the organizations or sites 12-18 in the supply chain 10 isconcerned with what to build and, given lead times and existinginventory, when to build and ship, so that the equipment ordered fromthe OEM 12 can be built and delivered in a timely fashion.

The present invention makes information regarding current orders, leadtimes, parts, etc. available to some or all of the supply chain sites,by collecting the data at a central site 16A and selectively publishingthat data to the other sites upon request. In the embodiment of FIG. 1B,the central site 16A is located at the distributor 16. In practice, theactual location could be anywhere. In one embodiment, it is controlledby the OEM 12.

FIG. 1C is a schematic diagram illustrating that part of the presentinvention to be employed at each participating supply chain site. Box 19represents any of the sites 12-18 of FIG. 1B. Each organization or site19 typically maintains its own data storage devices containing legacyinformation such as enterprise resource planning (ERP) data, materialresource planning (MRP) data, purchasing information, inventory, etc.

This information may be maintained, for example in text files such asASCII files 24, spreadsheets 22, and/or databases 20. The formats ofsuch data may be proprietary or customized. One site might use one typeof spreadsheet while another site uses another kind of spreadsheet.Similarly, one site might use a particular database while another siteuses a different database. Even databases bought from the same databaseprovider may be customized so that similar data is maintaineddifferently at different sites. Furthermore, some sites may not retaincertain data, having deemed it unimportant.

Before the development of the present invention, with all of thesedifferent legacy systems in place at the various supply chain sites 19,OEM verification of data, such as purchase orders and inventory, wasextremely difficult. The quality of data from the various sites 19 isclouded because there is no lowest common denominator.

In the past, teams of Information Technology software engineers havetypically re-engineered the existing systems. This can be a huge dataconversion and software integration effort, even at a single site, andbecomes much more problematic when trying to make the data uniformacross independent contract manufacturers and vendors who likely willnot be eager to redesign their business method and database. Even theElectronic Data Interchange (“EDI”) specification does not provideenough structure to ensure that users use it properly.

On the other hand, the present invention takes data as it exists on eachsite's legacy system. Data from all of the sites is collected at thecenter hub 16A, or data collection site, which is preferably thedistributor 16 or the OEM 12, and selectively published to the sites 19.

Data is retrieved from each site 19 by installing at each site a datatransfer engine (DTE) 26, preferably implemented in software. The DTEtakes data in any size or format, including various databases 24 and/orspreadsheets 22 and/or text files such as ASCII files 20, and corrects,translates and formats the data into “clean” data. In one embodiment,the DTE looks for changes to data and uploads new data to the datacollection site 16A upon finding a change. Alternatively, the DTE mayupload data upon some other trigger such as the end of a time period, ormay upload data in response to a request from the data collection site16A.

Communication between a site 19 and the data collection site 16A can beby any well-known means 40, for example, over the Internet or via adial-up connection, or via a virtual private network (VPN). In oneembodiment, the data is formatted using a formatting language such asXML. In one embodiment, all data transfers are encrypted. Web serversand browsers can also be employed.

The present invention is thus passive in that it takes whatever data asite has, for example, extracting data from any popular database, suchas Oracle, SAP, Sybase, Bahn, etc., or from spreadsheets such as Lotus,or any data reduced to an ASCII or EDI file, or any other formattedfile. No redesign or re-engineering is required.

FIG. 1D is a schematic diagram illustrating the components of thepresent invention employed at the data collection site 16A. A datacollection database 34 or an equivalent data storage system collects thedata sent by each DTE 26 (FIG. 1C). A publisher 36 receives queryrequests from the various sites 19, and depending on the access rightsgranted to a particular requesting site, formats and publishes therelevant supply-chain data to the requesting site, which then displaysthe data in a logical format as described below on a monitor 28 (FIG.1C).

Each site 19 which accesses the collected data requires one or morecomputers, each of which typically comprises a monitor 28 for showingthe requested information or report, a keyboard 30 for entering certaininformation, and a mouse 32 for navigating through the screens.

FIG. 1E is a flow chart 70 illustrating the general process of anembodiment of the present invention. A typical supply chain site 19 isshown on the left side of the figure while the data collection site 16Ais shown on the right side of the figure. Where possible, referencenumbers correspond to those used in FIGS. 1C and 1D.

The data transfer engine 26 extracts data in step 72 from variousformatted data, for example a database 20, an ASCII text file 24, or aspreadsheet 22. After the data is extracted, it is translated to acommon format in step 74 in one embodiment. After translation in step74, the data is uploaded in step 76 to the data collection site 16A wereit is received in step 78. Alternatively, translation could be doneafter upload. The received data is then collected and stored in, forexample, a database 34 (step 80).

This process of data extraction uploading and collection of the data atthe data collection site 16A can be preformed regularly, upon theexpiration of the predetermined time period or, for example, when achange in the data is detected at the supply chain site 19.

At some later time, a user requests certain data at step 82, at thesupply chain site 19. This request is forwarded to the data collectionsite. In response, the data collection site 16A formats the data (step84) and publishes the formatted data (step 86) to the supply chain site19. The published data is then view or stored or printed, as in step 88.

FIG. 2 shows a login or “splash” window 50 as might appear on a site'scomputer monitor 28 upon a user logging into the data collection site16A. The login window 50 builds on the theme of collaboration betweenthe contract manufacturers that produce the foundation of an OEM'sproducts. Preferably, images containing company names and/or logos ortrademarks are displayed for the OEM at 51, and for the contractmanufacturers at 53. In one embodiment, these images 51, 53 are links toconnect directly to the specific company. In the sample screen, thedistributor, whose logo 52 is displayed at the top, is the datacollection site.

Text entry blocks 55, 57 are provided for entering a user identification(ID) and password respectively. After entering these, a user clicks on“OK” 59 to have his ID and password verified, or clicks on “Exit” 61 toexit.

In the example embodiment, once a user has properly logged in, all datapertains to the specific OEM. In other embodiments, a distributor mightselect from among a plurality of OEMs, for example, via a pull-downmenu. In yet another embodiment, an OEM dealing with multipledistributors could select from among a plurality of distributors.

FIG. 3A is a screen shot 100 of circuit board data for all activeboards, sorted by board number. In one embodiment, this view 100 is thedefault screen shown to a user after a successful login.

Common to all screens after logging in is the set of tabs 102 whichallow the user to navigate quickly to the desired information. When the“Boards” tab 102A is selected, a list of filters 104A specific to thedisplay of board-related information is displayed. In the view 100shown, the filter list 104A is divided logically into two groups.

The first group of filters, labeled “Board Type”, comprises six filtersin the embodiment shown. By selecting a particular filter, the user canchoose to see only boards of a particular status, for example, boardsthat are classified as one of Active, Pre-production, Engineering orObsolete. In addition, in this particular embodiment, Active boards canbe sorted either by board number (“Active by Board”) or by contractmanufacturer (“Active by CM”). Finally, selecting “Combined” shows allboards. It will be obvious to one skilled in the art that other criteriafor selecting and sorting boards can be provided. Thus, materialsrequirements information may be viewed for products at all stages intheir lifecycle.

In the screen 100 of FIG. 3A, the “Board Type—Active by Board” filterhas been selected. That is, the user has requested information on allboards having a status of “Active”. All “Active” boards are listed inorder according to the OEM's board number.

The requested information for each “active” board is retrieved from thedata collection site's database 34 (FIG. 1C), sent by the publisher 36to the requesting site, and displayed on the requesting site's monitor28 in various columns or fields. This data may include, for example, theboard's OEM part number 106, name 108, manufacturer 110, status 112, andprojected delivery date 114, 116 for the corresponding manufacturer.

Because the user has selected the “Active by Board” filter, boards arelisted alphanumerically by board part number 106. Note that each entryin the board column has an arrow 107 for viewing a pull-down menu,described below with respect to FIG. 3B.

In the “Board Name” field 108, a board name is provided if it is knownto the system. The “Manufacturer” field 110 shows the name of a CM thatmanufactures the board. Note that each manufacturer can assign the sameboard a different name, or not assign any name at all.

The “Status” field 112 shows the status of each board. Of course,available statuses can be different according to the particular needs ofthe users and application, but in the illustrated embodiment, theavailable statuses are “Active” for boards which are currently utilizedby the OEM, “Pre-production” for boards which are in final approvalstatus by the OEM, that is, boards which are normally near complete,“Engineering” for boards which are in a pre-prototype or prototype stageand not yet used in production, and finally “Obsolete” for those boardsthat are not used in any present OEM machines, but which could, forexample, still be made for field upgrades, probably in limitedquantities.

The “Year” 114 and “Week” 116 fields show the projected delivery datefor the particular board from the CM shown.

Note that a board can be listed in multiple lines, one line for eachdistinct set of, in this example, board name, manufacturer, status, yearand week. For example, in FIG. 3A, the first three lines show a boardhaving a part number of 200-520-921. The first line indicates that CM-KKis one of the manufacturers of this board and is currently building thisboard.

The second line shows that a second contract manufacturer, CM-NN, alsomanufactures this board, and in addition calls the board a “Fiber DrtrBoard.”

The third line is again for boards ordered from the first CM, CM-KK, butfor a different scheduled delivery week.

Finally, a footer 118 displays the currently selected filter, here“Board Type—Active by Board.’

FIG. 3B shows a pull-down menu 120 which appears when the user holdsdown the mouse button over an arrow 107A in the board column 106.Selecting one of the three menu views displays detailed information forthe corresponding board.

FIG. 3C shows the displayed view 130 resulting when the “MRP for ALLCMs” view is selected from the menu 120 for part number 200-520-921,i.e., any of the first three lines of FIG. 3A.

A split screen, well-known to those skilled in the art, to allow thedisplay of non-contiguous portions 132, 134 of a view, is shown.Displayed data includes, for example, “Board” part number 136, “CM” 138,“Board Name” 140, “MRP Date” 142 and “Origin” 144 columns. Board Namecorresponds to the same column of FIG. 3A. MRP Date refers to the dateon which the CM must receive parts from the distributor or the componentmanufacturer. Origin indicates the location of the CM's plant where theboard is actually being manufactured (as in Cork, Ireland).

FIG. 4 shows a view 150 displayed when the “Boards Only” filter isselected under the “Using EC Parts” in the filter section 104. This view150 shows data about boards using parts carried by a particulardistributor, in this case IEC. Of course, if there were more than onedistributor, additional filters could be available to select boardsusing parts handled by those distributors as well. The “Board” 152,“Board Name” 154 and “Status” 156 columns correspond to the similarlynamed columns of FIG. 3A. If there were more than one OEM, for instanceif the data were being reviewed by a distributor who deals with multipleOEMs, additional filters could be available to list boards of particularOEMs.

Selecting “Boards and Parts” provides an exploded view (not shown) ofboards with additional detail based upon the Bill of Material, or BOM,for each board.

The view 160 of FIG. 5A is displayed upon the selection of the Parts tab102B. A new list of filters 104B, pertaining to parts, is available infilter partition 104. Here, the “EC Parts Demand” filter has beenselected, as indicated by its being highlighted and by the footer text118.

As with the parts views of FIGS. 3A-3C, several columns are displayed,including the OEM's part number 162, the vendor or manufacturer of thepart 166, the vendor's part number 168 for this part, the vendor'slead-time (“Lead weeks”) for this part, the “Buffer” 172, indicating anamount of inventory quantity, if any, that has been negotiated betweenthe OEM and distributor/component manufacturer to be kept on hand aboveand beyond committed stock, a “NCNR” indicator 174 which indicateswhether the item is non-cancelable, non-returnable, and a field 176labeled “Celestica Part.” Each additional CM which manufactures thispart has a corresponding column (not shown), which can be scrolled intoview using the scroll bar 177. Each of these CM columns, such as column176, shows the particular CM's part number for the corresponding part.

Note that customer part numbers, as these are commonly referred to, arecreated by the CM or OEM, and have significance that is beyond thecurrent transactional circle. Thus, a CM may have a customer part numberthat may apply to other jobs in addition to the one they perform for thecurrent OEM. This enables the CM to sort or use this data “companywide”.

In additional, there may be more than one vendor of a particular part.For example, the OEM's part number 004-368-101 is provided by twodifferent vendors, as shown in the second and third lines of FIG. 5A.Here, the OEM feels these parts are identical and can be “secondsourced” using the same number.

In fact, lines 5 and 6 of FIG. 5A indicate that two slightly differentnumbered parts (e.g., DS1232S/OEM-ZZ and DS1232S/TR/OEM-ZZ) from thesame vendor (VEND-BB) may be used to satisfy the distributor's part.Each part is shown in its own line.

Several filters 104B are provided. For example, sorting is available forparts profiles for a particular distributor such as IEC by NAED (ageneric industry-wide number assigned by the National Association ofElectrical Distributors), by manufacturer, or by the OEM's part numberor part class. A part class is, for example, a class of components, suchas resistors, perhaps of a certain wattage.

Cross reference filters are also available for OEM numbers and for eachcontract manufacturer. Finally, parts viewed with a parts profile can besorted by “Resale Price”, which is the resale price that the distributoror component manufacturer (the vendor) charges the CM.

As can be seen, other filter groups are available, such as “LeadTimes/Buffers,” in which parts are sorted, first by lead time (highestto lowest), then by buffer (highest to lowest), then by either OEM-ZZ,NAED or vendor part number, as selected. Filters are organizedhierarchically and the upper levels may be closed or opened (expanded)by the user to simplify viewing.

Another filter class is Inventory. Inventory levels can be illustratedby quantity, part type (fully cross referenced), and by chainparticipant, i.e., by CM, distributor, or component manufacturer.

Yet another filter class is Purchases. Purchases can be referenced asbacklog by the supplier, i.e., the distributor, or a vendor.

Selection of the IEC Parts Demand filter shows, going forward, whichparts are due out in what weeks.

An IEC Parts Admin selection is also available to provide administrativefunctions to privileged users.

As FIG. 5B shows, each line has a corresponding pull-down menu 180,through which a user can select detailed information such as “DemandThrough Lead Time” or “Demand Through Next Quarter.”

In FIG. 5C, the user has selected “Demand Through Lead Time” for theOEM's part number 012-000-021, and specifically, the manufacturer's partnumber DS1232S/TR/OEM-ZZ, which has a lead time of 6 weeks.

Detailed information for this part number is displayed, including, forexample, MRP Origin 192, which has the same meaning as “Origin” 144 inthe screen of FIG. 3C, the contract manufacturer 194 and those OEM'sboards 196 which use the OEM's generic part 012-000-021, or,alternatively, boards that specifically use the vendor'sDS1232S/TR/OEM-ZZ part.

The Week 31-35 columns 198 show quantities related to the part number,needed for each week for the particular board. Additional week columnsare off-screen, but can be scrolled into view.

Totals for each week are shown in the bottom row 199.

FIG. 6 is a screen view 200 of MRP data by board, obtained by selectingthe MRPs tab 102C. A variety of MRP-related filters 104C are available,providing a large degree of analysis of the supply chain data. Usingthese filters, for example, a match between the OEM's demand and theCM's demand as placed on the distributor/vendor can be easily shown.

Here, “OEM-ZZ (C)→CM-LL, MRP by Board” has been selected, indicating adesire by a user to review all boards ordered from contract manufacturerCM-LL for orders placed on it by, for example, the branch of the OEMindicated by “(C)”.

The data shown includes each qualifying circuit board part number 206,the name, if any, given to each circuit board 208, and quantities 210for, in this example, each week.

Similarly, FIG. 7A is a screen view 220 of vendor data, displayed whenthe Vendors tab 102D is selected. Various filters 104D, availableaccording to vendor, are selectable. The selected filter, VEND-DD, ishighlighted. Data shown includes circuit board part number 222, NAEDnumber 226, contract manufacturer CM-KK's part number 228, amanufacturing part number 230, and the manufacturer name 240.

In FIG. 7B, a pull-down menu 242 is available for each OEM part number,by clicking on the arrow 224 (FIG. 7A) next to the part number, allowingthe user to see all boards using that part.

FIG. 8 is a screen view 250 of sales data, which is displayed when auser selects the Sales tab 102E. A variety of sales-related analysisfilters 104E are provided. In the illustrated example, “Sales—By NAEDNumber” has been selected. Several columns of sales-related data aredisplayed, including CM 252. The first column 252 is labeled with thename of the OEM, here “OEM-ZZ”. Preferably, each account or location fora CM has a different name. For example, CM-LL8 is a specific account forvendor CM-LL.

Other columns include order number 254 from the CMs to the distributor,the NAED-assigned part number 256, discussed previously, the vendor'spart number 258, customer part number (PN) 260 corresponding to theOEM's part number and a quantity ordered 262 and quantity shipped 264.Note that the OEM is normally that entity that has “the customernumber”.

A CM Terms Admin selection allows an authorized user to performadministrative functions. Such functions can serve to quantify businessrules to a CM, including such terms as scheduling, buffer inventory andliability.

FIG. 9 is a view of the reports ordering window 270, displayed uponselection of the Reports tab 102F. A variety of analysis reports 104F,arranged hierarchically by topic, is available. Topics can include, butare not limited to, analysis reports, monthly shipment reports and daysales outstanding (DSO) reports.

A selected report can be sent to the screen, to a printer, to a file, orto a person via email, by selecting the respective button 272, 274, 280,286. “From page” and “To” fields 276, 278 allow the printing of onlyselected pages. File Name and File Type fields 284, 288 allow thedesignated report to be named and saved in a variety of formats. To,cc:, Subject and message fields, 288, 290, 292 and 294 respectively,allow the user to specify recipients of the report, and to add a subjectand remarks.

Note that in FIG. 9 a lead time analysis report has been selected in thefiltered 104f, and send report to screen 272 has been selected.

FIG. 10 is a screen shot 290 of a typical report sent to the screen forthe lead time report requested in FIG. 9.

The present invention traps conditions that will create problemsituations for the networked partners. When looming conditions ofsurplus or shortage become apparent by looking ahead at supply anddemand, an alert is raised by coloring the Alert tab 102G bright red. Ofcourse, in alternate embodiments, a flag or other icon, or, for example,an audible signal, could be used as well to indicate alert conditions.The screen 300A shown in FIG. 11A is displayed upon selection of theAlert tab 102G.

The alert window 300A is divided into two sections. The upper portion302 lists current alert conditions by alert type 304, origin 306, CM308, the OEM's number for the affected board 310, the OEM's part numberfor the actual part causing the alert of column 312, the manufacturer ofthe part 314 and the manufacturer's part number 316.

The lower portion 318 of the window 300A shows details of the currentlyselected alert condition 302A in graphical form. Bars are preferablycolor coded. For example, bar 322A could be light blue to indicate somestatus, while bar 322B could be green to indicate another status, bar322C could be yellow to indicate yet another status, and bar 322D is redto indicate alert status. Bar 321, indicating lead time, is dark blue.While different colors can be used, red is preferred for alertconditions to catch a user's attention. In particular, red preferablyindicates trouble on a lead time for a defined part number. Other colorsare for differentiation of lead-time periods.

In one embodiment, a bar is red to indicate that a product is overdueand not received. The left side of a bar indicates when a product isfirst due, while the right side of the bar indicates when all product isdue. A green bar, on the other hand, indicates the period during whichproduct is expected to be timely received. The left side of a green barcoincides with placement of an order. If a full shipment is received theentire bar is green. The right side of the green bar indicates the finalreceipt of a product.

Liability windows (LW) are also shown, defining a period of time withinwhich the distributor will be liable for the procurement of the subjectpart if an order is cancelled. This period is indicated by the width ofthe LW bar, which in one embodiment is yellow. If the distributorcancels outside that timeframe, then no liability exists. Liabilitywindows can differ among part number and by vendors. When a user clickson a LW bar, a number of day(s) of the LW appears in a pop-up window.Since this number defines the LW, the distributor can cancel anyquantity due without liability if such cancellation is for product duebeyond the right side of the LW bar.

As this example suggests, an unexpected production plan increase isimpacting the supply chain. Here, the problem week, week 13 of 1999 asindicated by bar 319, is viewed in relation to the purchases that havebeen made for that part. Details of each bar include, for example,purchases, deliveries, and delays that can conspire to aggravate ademand condition.

Individual line items, such as 302A or 302B, can also be color coded toindicate a particular status.

Similarly, any of the lines containing boards or part information, asdepicted for example in any of FIGS. 3A-8, can also be color-coded toindicate status, in particular, an alert condition. Either thebackground or the text itself can be color coded.

In one embodiment, navigating to the screens depicted in FIGS. 11B, 11Cand 11D is done by clicking the right mouse button on a blank part ofthe screen of FIG. 11A. A pop up window appears (not shown). The userselects “sales” to go to the screen of FIG. 11B, or “quantities” to goto the screen of FIG. 11C or FIG. 11D.

Also, by clicking on a bar 322D on the graph 318, the screen 300B ofFIG. 11B is displayed. This view displays the same problem event in thecontext of sales of the product that can yield an unattainableobligation unless measures are taken immediately.

In FIG. 11C, the bottom portion 330 of the screen 300C shows quantitylevels for the problem part. Preferably, the different quantities arecolor-coded. The available data analysis can make visible the resultingexpected shortage that too often occurs, and meets with an untimelyresponse that has already broken the efficiencies of the manufacturingprocess.

Current MRP is the MRP data that was last received. Previous MRP is theMRP information received just before the last. Changes to the MRP can beviewed here. In this example, the previous MRP called out for 500pieces, while the current calls out for 1000 pieces. Thus, a 500-pieceshortage has been created.

On-hand is inventory, and is preferably categorized by each distributor,the CM's and the vendors. It is important to have access to all stockpositions on an ongoing basis.

FIG. 11D presents an alternate alert screen view for use in oneembodiment of the present invention. Panel 352 allows a user to viewalerts pertaining only to certain vendors or parts, etc. In addition,rather than using bars to portray data, a graph 354 is used.

FIG. 12 is a graph 400 illustrating the use of animation by the presentinvention to present data. The present invention is based upon state ofthe art technologies that lend themselves to analysis and modeling oftrends. This affords a novel opportunity to put the aggregate data touse in viewing the dynamics of the supply chain.

The graph 400 can be viewed by selecting an icon in a toolbar (notshown). By clicking on a “play” button (not shown) next to the graph400, the user is presented with multi-dimensional views of the data,including animations of the data over time, which enable the discoveryof conditions that can be smoothed to the advantage of all partners inthe supply chain.

In FIG. 12, the sum of orders is negative when there are not enoughorders to fulfill requirements.

With the analysis tools described above, if a vendor does not have asufficient quantity of parts, the distributor can easily find a CM whohas surplus parts to sell to another CM who needs the parts.

The present invention provides feedback to CMs and vendors, pointing outtheir weak spots, and showing where they can strengthen their positionby cleaning up their data.

While the present invention has been shown in a distributor's supplychain, it can also be used anywhere there is a supply chain, such as inretail, wholesale, the food industry, etc.

It will be apparent to those of ordinary skill in the art that methodsinvolved in the present system for monitoring a supply chain may beembodied in a computer program product that includes a computer usablemedium. For example, such a computer usable medium can include areadable memory device, such as a hard drive device, a CD-ROM, aDVD-ROM, or a computer diskette, having computer readable program codesegments stored thereon. The computer readable medium can also include acommunications or transmission medium, such as a bus or a communicationslink, either optical, wired, or wireless, having program code segmentscarried thereon as digital or analog data signals.

While this invention has been particularly shown and described withreferences to preferred embodiments thereof, it will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the scope of the inventionencompassed by the appended claims.

1. A data importation method comprising: receiving first product data in a first format; comparing the first product data with second product data previously received; reviewing results of the comparison to determine whether there is a problem with the first product data; changing a format of the first product data to a standard format; comparing the standard format first product data with third product data, the third product data corresponding to the second product data having format changed to the standard format; placing the standard format first product data in a category based on the comparison of the standard format first product data with the third product data; and generating statistics based on the comparison of the standard format first product data with the third product data.
 2. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in an identical products file.
 3. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in a new products file.
 4. The method of claim 3, further comprising: retrieving original supplier data for an original supplier product; normalizing at least one company in the retrieved supplier data; looking up the original supplier product in a product database to determine whether data corresponding to the original supplier product has been provided by other suppliers; locating a template for the original supplier product corresponding to the retrieved supplier data; normalizing at least one attribute from the retrieved supplier data by using the template; defining normalized product data as the supplier data having the normalized at least one company and the normalized at least one attribute; and inserting the normalized product data into the product database.
 5. The method of claim 4, wherein the step of normalizing at least one company comprises normalizing vendors and manufacturers associated with the product.
 6. The method of claim 4, wherein the looking the product up step comprises determining whether the retrieved product data already exists in the product database.
 7. The method of claim 6, further comprising: comparing the normalized at least one attribute with existing attributes; selecting correct attribute values; and updating the normalized product data in the product database with the correct attribute values.
 8. The method of claim 4, further comprising a step of updating attribution definitions before the step of inserting the normalized product data.
 9. The method of claim 4, further comprising: identifying a category associated with the original supplier product; retrieving original supplier data for other original supplier products; and optionally assigning to the located template all products in the other supplier original products corresponding to the identified category.
 10. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in a changed products file.
 11. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in a deleted products file.
 12. The method of claim 11, further comprising: retrieving product data from the delete products file; looking up the retrieved product data in the product database; deleting from the database the retrieved product data, which corresponds to a first supplier, when a product corresponding to the retrieved product data has not been deleted for all other suppliers.
 13. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in a faulty products file. 